Компания VMware сделала доступной небольшую онлайн-утилиту для сайзинга серверов хранения виртуальных машин, работающих в отказоустойчивых кластерах хранилищ - VMware vSAN Sizer. Также она производит подбор необходимых конфигураций серверов (для расчетов принимается, что все узлы будут использовать конфигурацию All-Flash SSD).
От пользователя требуется лишь ввести число виртуальных машин и объем их виртуальных дисков (пока указано, что для расчета используется некий усредненный тип нагрузки, возможно, в будущем будут добавлены еще профили нагрузок ВМ).
На первом этапе нам показывают, сколько нужно серверов и неразмеченного хранилища (Raw Storage):
Ниже мы видим технические характеристики каждого из хостов ESXi:
Ну а в рамках дополнительной информации можно вывести параметры дисковых групп (кэш и емкость хранения). В моем случае это 2 дисковых группы:
В утилите VMware vSAN Sizer расположена ссылка на расширенную версию, которая доступна для партнеров, но когда я зашел под партнерским аккаунтом, то увидел там только пустую белую страницу с шапкой меню.
Как вы знаете, в новой версии решения организации отказоустойчивых кластеров VMware vSAN 6.6 появилась возможность шифрования хранилищ. В целях увеличения эффективности и скорости работы в этой технологии используется концепция "encryption at rest". Сначала данные в незашифрованном виде идут по сети (в целях ускорения и работы сжатия), затем они в зашифрованном виде падают в кэш. После чего, перед тем, как отправиться на постоянное хранение (destaging), они будут расшифрованы, дедуплицированы/сжаты и снова зашифрованы уже на целевом устройстве.
Очевидно, что это удобно и эффективно с точки зрения экономии дискового пространства, но несколько небезопасно, так как из кэша можно потенциально достать незашифрованные данные. Поэтому и существует технология VM Encryption, лишенная этого недостатка, но неэффективно расходующая диск.
Для работы шифрования vSAN нужно, чтобы в кластере была версия on-disk format 5 или выше, при этом пятая версия появилась только в vSAN 6.6. Здесь возможны 3 сценария использования шифрования vSAN:
Развертывание кластера с нуля на vSAN 6.6.
Апгрейд кластера с vSAN 5.x./6.x на 6.6 со сменой on-disk format на версию 5.
Апгрейд кластера с vSAN 5.x./6.x на 6.6 без изменения версии on-disk format.
В первом случае шифрование данных можно будет включить сразу же для нужного хранилища. Это добавит специальный тэг в метаданные тома, после чего все новые данные, передаваемые из кэша на диск, будут зашифрованы.
Во втором случае мастер миграции может выполнить процедуру DFC (disk format change), что поменяет on-disk format на версию 5. Далее также можно будет включить шифрование в любой момент, и с этого момента новые данные тома будут шифроваться. При этом не потребуется убирать виртуальные машины с хранилища
Ну а вот в третьем случае (когда в процессе апгрейда вы не прошли процедуру DFC), понадобится переместить все виртуальные машины с нужного тома, чтобы включить на нем шифрование. Это может вызвать некоторые неудобства, поэтому лучше всего воспользоваться вариантом один или два.
В статье о новой версии продукта для организации отказоустойчивых кластеров хранилищ vSAN 6.6 мы писали о том, что появилась утилита Configuration Assist, созданная для того, чтобы после установки кластера правильно сконфигурировать среду vSphere, чтобы все работало корректно и соответствовало необходимой конфигурации платформы.
Первоначальные задачи по настройке кластера, развертываемого через Easy Install или vSphere Web Client, включают в себя настройку порта VMkernel для трафика vSAN, выделение дисков и т.п. Как часть процесса установки, мастер vSAN Setup Wizard заботится о таких специфических вещах, как дедупликация и компрессия, число узлов, растянутый это будет кластер или нет, но не заботится об общих настройках среды VMware vSphere.
Для этого и был сделан раздел vSAN Configuration Assist, который вам поможет со следующими операциями:
Настройка высокой доступности vSphere High Availability.
Конфигурация vSphere Distributed Switch для трафика vSAN.
Настройка vMotion для ВМ.
Позволит убедиться в том, что все доступные накопители используются для кластера.
Есть средства конфигурации хостового контроллера.
Есть необходимая версия микрокода (firmware) хостового контроллера.
Все эти задачи можно выполнить из различных разделов vSphere Web Client, но мастер Configuration Assist позволяет сделать это в единой точке интерфейса как часть рабочего процесса по конфигурации кластера vSAN. Ну и важный момент, что это своего рода чеклист необходимых задач постконфигурации кластера хранилищ.
Вот как это примерно делается (приведен пример, как настроить для vSAN или vMotion интерфейсы VMKernel):
Выделение дисков под кластер идет в момент его развертывания, но после установки это уже можно сделать через Configuration Assist:
Конечно же, необходима настройка vSphere HA/DRS:
Ну и последнее, но не менее важное - утилита позволяет вам обновлять микрокод узлов различных OEM-производителей, таких как Dell, Lenovo, Fujitsu и SuperMicro:
Поэтому первым делом после развертывания кластера vSAN идите в раздел Configuration Assist клиента Web Client.
Таги: VMware, vSAN, vNetwork, VMachines, Storage, HA, Web Client
Хорошим дополнением к этому будет видео ниже, в котором в течение 80 минут рассказывается о тонкостях возможностей продукта с технической стороны (правда там нет обзора фич последних версий 6.5/6.6).
Видео предназначено для тех, кто хочет понять, как работает кластер vSAN, что такое Disk Object, Storage Policies, как работает флэш-кэш, растянутый кластер и другие штуки. Если вас не раздражает индусский английский, то видео вполне интересное.
Ну а вот еще несколько видео о последнем vSAN 6.6 и его новых возможностях, которые также могут быть полезными:
Интересный пост написал Cormac Hogan, касающийся конфигурации растянутых кластеров VMware vSphere Stretched Clusters и размещения компонентов Witness VM для них. Если у вас есть 2 площадки и два растянутых кластера VMware vSAN между ними, то сама собой напрашивается следующая конфигурация:
Но так делать, конечно же, нельзя - и вот почему. Допустим у вас отказал сайт 2, на котором не было Witness-машин. Только в этом случае у вас будет все хорошо - для каждого из кластеров будет кворум (Witness VM+узел), и они продолжат нормальную работу.
Но если у вас откажет сайт 1, то вы лишитесь сразу двух Witness VM (и WA, и WB), узлы на площадке 2 окажутся изолированными, и все виртуальные машины на них будут недоступны (нет кворума):
А что для случая, если машины Witness VM разместить на разных площадках?
Да тоже ничего хорошего - откажет сайт 1, вследствие чего виртуальные машины выжившего сайта 2 кластера A будут недоступны (не будет кворума, ведь WA, присматривающий за эти узлом умер на первой площадке). Ну а поскольку WB является как раз виртуальной машиной, данного узла кластера A ставшего недоступным, то и у выжившего узла кластера B также не будет кворума. В итоге и виртуальные машины кластера B при данном сбое будут недоступны.
Поэтому нельзя перекрестно конфигурировать Witness VM для двух растянутых кластеров на двух площадках - нужно использовать третью площадку, чтобы кворум обеспечивался при любом виде сбоя на уровне одного из сайтов.
Те из вас, кто следят за обновлениями решения для организации кластеров хранилищ VMware vSAN, знают, что в версии vSAN 6.6 появилась возможность обеспечивать избыточность на уровне локального сайта и на уровне двух площадок растянутого кластера (stretched cluster) в то же самое время.
Напомним, что для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1 (на обычных дисках), а также RAID-5 или RAID-6 (для архитектуры All-Flash).
Это, кстати, означает, что при полном отказе одного из сайтов растянутого кластера, виртуальные машины выжившего сайта все еще будут защищены на уровне отдельных хостов или виртуальных дисков. Единственное, что для этого компонент Witness должен быть доступен. Ну и, само собой, при отказах дисков/хостов внутри площадки виртуальные машины также будут защищены в соответствии с политикой SFTT.
Все это вызывает логичный вопрос - а как планировать емкость обеих площадок, на которых работает vSAN? Кстати, нельзя называть эти площадки основной и резервной, так как они работают в режиме Active-Active.
Традиционно, до введения политик избыточности на уровне каждой из площадок, планирование емкости было простым - надо было просто удвоить исходную емкость одной площадки. В vSAN 6.2 появилась не только защита RIAD-1 (mirroring), но и RIAD-5/6 (erasure coding), что позволяет в рамках растянутых кластеров организовать различные схемы размещения данных. Отметим, что алгоритм erasure coding между площадками пока не реализуем ввиду ограничений на уровне домена отказа (Fault Domain). Поэтому между площадками - только Mirroring.
Учитывая все это, в VMware сделали единую табличку, которая поможет вам при планировании емкостей инфраструктуры vSAN как для растянутого кластера, так и для кластера в рамках одной площадки:
В поле PFTT для растянутых кластеров мы видим 1, а для обычных 0. FTM (Failure Tolerance Mode) - это режим обеспечения отказоустойчивости на уровне каждого из сайтов. Напомним, что для обычных дисков он может быть только Mirroring, а для All-Flash архитектур - Mirroring или Erasure Coding.
SFTT определяет число отказов дисковых объектов внутри площадки, которое сможет перенести каждая из площадок вашего растянутого кластера.
Таким образом, если вы организуете растянутый кластер хранилищ на базе архитектуры All-Flash со средствами защиты Erasure Coding в рамках площадки и Mirroring между площадками, то вам потребуется 266% исходной дисковой емкости виртуальных машин (ее можно скорректировать на экономию от Thin Provisioning).
Ну а если вы будете использовать обычные диски и защиту Mirroring как внутри площадки, так и между площадками - вам потребуется 400% исходной емкости.
В довершение нужно обязательно отметить, что администратор не может контролировать, где будут размещаться дисковые объекты ВМ в пределах одного сайта (то есть не получится обеспечить распределение дублированных копий объектов на уровне серверных стоек одной площадки).
Недавно мы писали об анонсированных новых возможностях продукта для организации кластеров хранилищ VMware vSAN 6.6, а вчера он стал официально доступен для скачивания. Так как VMware vSAN работает в рамках инфраструктуры серверной виртуализации VMware vSphere, были также выпущены обновления ESXi 6.5d и vCenter 6.5d, поддерживающие vSAN 6.6.
Напомним также, что совсем недавно выходил апдейт VMware vCenter 6.5c, в котором была исправлена уязвимость компонента Apache BlazeDS. Что касается обновления ESXi 6.5d, то оно включает в себя поддержку vSAN 6.6, исправления некоторых ошибок а также отображения статусов VMware vSAN health checks в интерфейсе клиента ESXi Host Client (он же Embedded Host Client).
Загрузить VMware vSAN 6.6 в составе платформы VMware vSphere 6.5 и ее компонентов можно по этой ссылке.
Пару дней назад мы писали о новых возможностях последней версии решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.6. А совсем недавно известный блоггер Дункан Эппинг выпустил два интересных видео, посвященных данному продукту.
Первое - это общий обзор VMware vSAN 6.6, в котором Дункан проходится по основным нововведениям, наглядно демонстрируя их в интерфейсе:
Во втором видео Дункан подробно останавливается на технологии шифрования vSAN 6.6, показывая ее в деле:
Ну и в довершение - интересный документ с детальным рассмотрением технических особенностей новой версии VMware vSAN 6.6 (уже не от Дункана, но очень подробный и полезный для администраторов решения):
Осенью прошлого года компания VMware на конференции VMworld Europe 2016 представила новую версию продукта VMware Virtual SAN 6.5, которая была приведена в соответствие с версией vSphere 6.5. На днях, спустя полгода после этого релиза, была представлена обновленная версия этого продукта для создания кластеров хранилищ - VMware vSAN 6.6 (обратите внимание, что он теперь называется не Virtual SAN, а vSAN).
Несмотря на малое продвижение версии, в VMware vSAN 6.6 появилось весьма много новых возможностей:
1. Шифрование.
В vSAN 6.6 появился механизм DARE – Data At Rest Encryption. Несмотря на то, что для ВМ на платформе vSphere 6.5 есть собственное шифрование, ранее для такого сценария не были доступны дедупликация и компрессия. Теперь за счет того, что шифрование vSAN работает на более позднем уровне - эти механизмы экономии дискового пространства теперь поддерживаются.
Кроме того, эта возможность использует механизм AESNI (Advanced Encryption Standard Native Instruction), который есть во всех современных процессорах, что увеличивает производительность. Также появились новые healthchecks касающиеся того, что сервер KMS доступен (не забудьте обеспечить его резервирование), а также хосты поддерживают AESNI.
2. Механизм локальной защиты для растянутых кластеров (vSAN Stretched Clusters).
Теперь средствами политик можно определить уровень защиты как на уровне локального сайта, так и на уровне межсайтового кластера. Для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1, RAID-5 или RAID-6.
Это, кстати, означает, что при полном отказе одного из сайтов растянутого кластера, виртуальные машины выжившего сайта все еще будут защищены на уровне отдельных хостов или виртуальных дисков. Единственное, что для этого компонент Witness должен быть доступен.
Надо отметить, что администратор не может контролировать, где будут размещаться дисковые объекты ВМ в пределах сайта (то есть не получится обеспечить распределение дублированных копий объектов на уровне серверных стоек одной площадки).
3. Возможность Site Affinity для растянутых кластеров.
Теперь машину можно привязать к определенной площадке для растянутого кластера, но только в том случае, если у нее установлено Primary level of failures to tolerate в значение 0 (то есть она не защищена на уровне кластера vSAN, а администратор сам заботится о средствах ее защиты).
4. Режим Unicast Mode.
Теперь вместо мультикаста используется юникаст для коммуникации между узлами кластера. Как только вы обновите все хосты кластера vSAN да версии 6.6 - он сам переключится на режим Unicast:
Вот этой командой можно проверить режим Ubnicast на узлах кластера:
Если раньше можно было просматривать только объекты VMDK и VM Home, то теперь добавился Swap и объекты дельта-дисков ВМ для снапшотов (см., например, диск с именем Hard disk 9 -vcsa-06.rainpole.com_8.vmdk):
6. Возможности Smart Rebuilds.
В прошлых версиях vSAN никогда не использовал старый компонент, если начиналась процедура ребилда нового. То есть, если хост выходил из строя, например на больше чем 60 минут, то его компоненты уже не могли быть использованы.
Теперь же эта штука работает умнее - в случае если после 60 минут хост вышел в онлайн, то сравниваются затраты на использование его старых компонентов и ресурсы на ребилд новых, после чего выбирается наиболее эффективный способ синхронизации дисковых объектов.
Также при высоком заполнении дискового пространства (более 80%) дисковые объекты могут разбиваться на более мелкие чанки, чтобы можно было отбалансировать распределение этих кусочков по хостам кластера в целях более эффективного использования дискового пространства.
7. Механизм Partial Repairs.
В прошлых релизах vSAN, если все компоненты объекта не могли быть восстановлены в результате сбоя, то vSAN не начинал процедуру восстановления (Repair). Теперь же процедура восстановления начнется, даже если компоненты объекта доступны лишь частично - это позволяет частично защититься от дальнейших сбоев в кластере, так как часть восстановленных компонентов будет снова задублирована.
8. Функция Resync Throttling.
Это давно ожидаемая фича - она позволяет задать ширину канала для ресинхронизации в Mbps:
Кроме того, был улучшен сам механизм ресинхронизации - раньше он мог начинаться сначала, если был прерван до завершения. Теперь же он всегда продолжается с последнего прерванного момента.
9. Новые пречеки для режима обслуживания.
Теперь перед переводом кластера в режим обслуживания vSAN делает предпроверки на доступную емкость, чтобы не попасть в ситуацию нарушения политик на время обслуживания:
10. Новые пречеки для удаления дисковых групп и дисков.
По аналогии с пречеками для режима обслуживания, теперь при списании дисковых групп или дисков можно узнать, каким образом данная операция скажется на соблюдении политик:
Такая же штука доступна для отдельных дисков. Это можно оказаться очень полезным при апгрейде хранилищ на хостах ESXi:
11. Новый помощник установки и развертывания.
Теперь процедура развертывания кластера vSAN стала значительно проще благодаря улучшенному установщику:
А для проверки конфигурации кластера vSAN появилась утилита "Configuration Assist", которая позволяет убедиться, что все настроено правильно:
12. Средства для проактивного предупреждения ошибок.
Теперь за счет механизма CEIP (Customer Experience Improvement Program) информация о кластере vSAN посылается в VMware, облачные системы которой могут выдавать предварительные предупреждения о возможных проблемах в инфраструктуре хранилищ и рекомендации по их настройке.
13. Интеграция с HTML5 Host Client.
Теперь для кластера vSAN появилась интеграция с клиентом для управления серверами ESXi, где можно, среди прочего, посмотреть состояние различных компонентов узла vSAN:
Также, например, можно прямо из клиента HTML5 управлять средствами дедупликации vSAN.
14. Новые команды ESXCLI.
Были добавлены следующие пространства команд для управления кластером vSAN и его новыми фичами:
esxcli vsan debug
esxcli vsan health cluster
esxcli vsan resync bandwidth
esxcli vsan resync throttle
15. Возможность заменить компонент Witness прямо из GUI.
Теперь в интерфейсе для этого появилась специальная кнопка:
Сразу после релиза обновленной версии платформы vSphere
5.5 компания VMware выпустила очень интересный и полезный документ Performance Best Practices for VMware vSphere 5.5, в котором
рассматриваются аспекты производительности серверов VMware ESXi и виртуальных машин уже с учетом функциональности новой версии.
Например, теперь в документе описаны следующие фичи в контексте производительности:
Функции кэширования на SSD-накопителях vSphere Flash Read Cache, о которых мы писали вот тут. Они увеличивают производительность за счет применения кэша на чтение для операций ввода-вывода виртуальных
машин.
Возможность VMware Virtual SAN (VSAN), о которой мы писали тут.
Она позволяет использовать локальные ресурсы хостов ESXi для построения распределенной инфраструктуры хранения виртуальных машин.
База данных VMware vFabric Postgres database (vPostgres).
Кроме того, были обновлены и дополнены следующие темы в документе (который уже можно смело называть книгой, так как занимает он 90 страниц):
Использование нагрузок в ВМ, чувствительных к скорости подсистемы ввода-вывода и сетевому взаимодействию (интересна также статья в тему)
Техники NUMA и Virtual NUMA (vNUMA)
Техники экономии памяти хоста (Memory overcommit)
Технология Large memory pages
Техника Receive-side scaling (RSS), как в гостевых ОС, так и для адаптеров 10 Gigabit Ethernet
Средства миграции VMware vMotion, Storage vMotion, а также Cross-host Storage vMotion
Техники балансировки нагрузки VMware Distributed Resource Scheduler (DRS) и экономии электропитания Distributed Power Management (DPM)
Обновленный (а точнее полностью переписанный) VMware Single Sign-On Server (об этом у нас тут)
Некоторое время назад мы уже выкладывали интерактивные демо продуктов VMware, но с тех пор уже много воды утекло, и демки устарели. На прошедшей конференции VMworld 2013 компания VMware анонсировала новые версии своих продуктов, например, VMware vSphere 5.5 и vCloud Director 5.5, а к ним она приложила интерактивные демо, воспользоваться которыми в целях обучения может любой желающий.
Не так давно мы уже писали о технологии виртуальных томов vVOL, представленной на VMworld 2012, которая позволит дисковым массивам и хостам оперировать с отдельными виртуальными машинами на уровне логического дискового устройства, реализующего их хранилище, что повысит производительность и эффективность операций с ВМ.
Там же, на VMworld 2012, компания VMware представила технологию vSAN, реализующую распределенное хранение данных ВМ на локальных хранилищах хост-серверов VMware ESXi (Distributed Storage):
Концепция vSAN, включающая в себя Distributed Storage, является продолжением существующего подхода к организации общих хранилищ виртуальных машин на базе локальных дисков серверов - VMware vStorage Appliance. Работает это средство обеспечения отказоустойчивости хранилищ за счет полного дублирования хранилищ одного из узлов кластера, а также репликации данных между ними:
Теперь же, в скором времени в гипервизор VMware ESXi будет включена технология Distributed Storage, которая позволит агрегировать вручную или автоматически дисковые емкости (HDD и SSD) хост-серверов в единый пул хранения с функциями отказоустойчивости и кэширования:
Разрабатывается эта концепция на волне распространения SSD-накопителей в серверном оборудовании и СХД. Единый пул хранения кластера Distributed Storage будет не только объединять диски серверов (туда добавляются диски без созданных разделов с определенным администратором вкладом емкости в общий пул) и предоставлять пространство хранения виртуальным машинам на любом из хостов, но и будет управляем средствами политик механизма Policy-Based Storage Management. Интересно то, что размер кластера хранилища для Distributed Storage будет равен размеру кластера хостов (сейчас 32), в рамках которого все хосты имеют возможность использовать агрегированную емкость пула, даже те серверы, что не имеют дисков вовсе.
Все это будет интегрировано с механизмами HA, vMotion и DRS в целях обеспечения отказоустойчивости и балансировки нагрузки на хост-серверы. Кроме этого, агрегированный пул хранилищ будет поддерживать все основные технологии VMware для работы с хранилищами: снапшоты ВМ, связанные клоны, vSphere Replication (vR) и vStorage APIs for Data Protection (vADP).
С точки зрения политик хранения, Distributed Storage будет предоставлять следующие варианты для каждой виртуальной машины:
Доступная емкость и объем ее резервирования.
Уровень отказоустойчивости (степень дублирования данных на узлах = количество реплик).
Уровень производительности (какое количество SSD-кэша выделить для обслуживания реплик, а также число страйпов для диска ВМ, если необходимо).
Данные в кластере VMware Distributed Storage хранятся на локальных дисках узлов по схеме RAID-1, так как это дает максимальный экономический эффект с точки зрения затрат на 1 IOPS при условии комбинирования HDD-хранилищ данных и SSD-хранилищ кэша и данных (подробнее тут). SSD-кэш работает как фронтэнд для HDD-дисков, обрабатывая кэширование чтений и буферизацию записи для операций кластера, при этом сделано множество оптимизаций кэша для увеличения вероятности попаданий в кэш при чтении данных ВМ с дисков различных узлов.
Ну а на практике vSAN уже работает в лабораториях VMware, где инженеры демонстрируют возможности Distributed Storage:
Информации о времени доступности технологии VMware Distributed Storage пока нет. Возможно, базовые функции vSAN будут реализованы в VMware vSphere 6.0.
RSS
